1. Field of the Invention
The present invention is directed to ways to create and manage websites and their content. More particularly, the invention is directed to an object-oriented way to create and manage dynamic websites and their content.
2. Description of the Related Art
Today, web pages and their content are typically created, managed and delivered using a variety of tools and systems. Programming tools (e.g. Adobe Dreamweaver™) are commonly used for web page creation, and authoring tools (e.g. Microsoft Word™ or Adobe PhotoShop™) are commonly used for content creation. Content Management Systems (e.g. Drupal™ or OpenCMS™) may also be used for controlling and transforming content after it has been created, and version control systems and database and web servers are used for storing and delivering the web pages and their content to end user browsers.
While in some cases it may be valuable from a “separation of concerns” perspective (i.e. having the creative department use one set of tools, and the IT department use others), the use of tools and systems that are not integrated makes it necessary to integrate the work product of each department in a separate, final step to permit a given web page and its content to be published to the Internet. One problem with this approach is that it is time consuming, and this problem is exacerbated by the tendency that websites (and their content) are rarely static. Almost all websites change frequently, being updated constantly to reflect changes in the organization or individual publishing the website or in its (or his/her) environment.
The absence of an integrated system makes creating and revising content and a set of web pages on a website (or on any given web page of a website) unduly difficult in terms of both effort and complexity. Once design mock-ups and digital assets (e.g. art, photos, and videos) have been developed, the website's web pages are built with these design elements using HTML, CSS and JavaScript programming languages to achieve the effects called-for in the design. Next (or in parallel), news articles, product data sheets and other information are developed to form the content for the site.
At this point the user faces a choice of whether or not to use a Content Management System (a “CMS”). Content Management Systems are typically employed if the content on a web site is expected to change frequently. If not, then the website publisher will typically “hard-code” the content directly into each web page file.
If a CMS approach is chosen, the next step is to place all content items into a relational database, and to turn each web page file (via programming) into a “page template” that is bound to the CMS. The CMS then dynamically (or, in some systems, statically during a compilation process) creates individual web pages of a website by combining the content in the database with the layout, presentation and behavior defined in the web page template. At this point, the final web page is ready for delivery to an end user's browser.
A significant problem with the technologies and processes described above is that it is very difficult to build and integrate all of the content and web page (i.e. layout, presentation, and behavior) components needed for a sophisticated website. If a CMS is employed to manage content changes, the initial build is even more difficult, and even if a CMS is employed, it is still very difficult to make subsequent changes to site structure (“site map”) and web page components without involving considerable programming.
For illustration, consider this simple example:
Without a CMS, combining content and web page visual aspects (layout, presentation and behavior) may be done like this using HTML and JavaScript:
  <body>   <div>  style=“background-color: yellow”;    onclick=“showMenu(someElementID)”  onmouseover=“this.className=fredHighlight”onmouseout=“this.classname=“fred”  class=“fred”>    <p>    This is some text  </p>   </div>  </body>
The above code would produce a section on a web page with a yellow background color (layout and presentation) as well as set up some code to handle mouse clicks, etc. (behavior). Finally, it would display the line “This is some text” (content) on the page.
Using a CMS, the above code would become:
<body> <div>style=“background-color: yellow”;onclick=“showMenu(someElementID)”onmouseover=“this.className=fredHighlight”onmouseout=“this.classname=“fred”class=“fred”>  <p>  $Content</p> </div></body>
The term “$Content” is a variable whose value (e.g. “This is some text”) is defined and stored in a database that is populated by the website publisher. If the value of $Content is indeed “This is some text”, then the CMS code above would produce, from the end user browser's perspective, exactly the same web page and content as the non-CMS code above. However, note that by implementing the CMS, the content in the database could be changed to any value (say, for example, “Hello World”) and this would be automatically displayed on the web page the next time it is rendered.
The CMS approach therefore provides an improvement relative to the hard coding of all content into individual web pages in situations where the content is expected to change relatively frequently. However, the CMS approach also has significant drawbacks in that it does not facilitate changes in web page visual aspects. What if, for example, a website publisher wants to change the background color, or more interestingly to change what happens when the end user browser clicks or hovers on certain elements within a web page? How would the publisher add an entirely new web page to display new content?
Changes of this sort are examples of changes to web page visual aspects (including structure, layout, presentation and behavior), and cannot be implemented using current technologies without additional programming.